<h1>Resumen libro scrum y xp desde las trincheras</h1>

<h2><br />
Capitulo 1</h2>

<p><strong>Introducci&oacute;n</strong></p>

<p>En palabras de Ken Schwaber, Scrum no es una metodolog&iacute;a, es un marco de<br />
trabajo. Eso quiere decir que Scrum no te va a decir exactamente lo que debes<br />
hacer.</p>

<p><br />
Las buenas noticias son que te voy a decir exactamente como empleo Scrum,<br />
con una cantidad terriblemente dolorosa de detalles. Las malas noticias son que,<br />
No significa que tu debas hacerlo<br />
exactamente de la misma forma. De hecho, probablemente yo mismo haga las cosas<br />
de una manera diferente si me encuentro en una situaci&oacute;n diferente. La<br />
fuerza y lo duro de Scrum es que est&aacute;s obligado a adaptarlo a tu situaci&oacute;n especifica.</p>

<h2>Capitulo 2</h2>

<p><strong>Pilas de Producto</strong></p>

<p>La pila de producto es el coraz&oacute;n de Scrum. Es donde empieza todo. La Pila de<br />
Producto es, b&aacute;sicamente, una lista priorizada de requisitos, o historias, o<br />
funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la<br />
terminolog&iacute;a del cliente. Llamamos a esto historias, o a veces simplemente<br />
elementos de la Pila.</p>

<p>Nuestras historias incluyen los siguientes campos:</p>

<p><br />
&bull; ID &ndash; un identificador &uacute;nico, simplemente un n&uacute;mero auto-incremental .<br />
Esto nos permite no perder la pista a las historias cuando cambiamos su<br />
&nbsp;nombre.</p>

<p>&bull; Nombre &ndash; una descripci&oacute;n corta de la historia.</p>

<p>&bull; Importancia &ndash; el radio de importancia que el Due&ntilde;o de Producto da a esta historia.&nbsp;</p>

<p>&bull; Estimaci&oacute;n inicial &ndash; la valoraci&oacute;n inicial del Equipo acerca de cuanto trabajo es<br />
necesario para implementar la historia, comparada con otras historias.&nbsp;</p>

<p>&bull; Como probarlo &ndash; una descripci&oacute;n a alto nivel de como se demostrar&aacute; esta historia<br />
en la Demo al final del Sprint.&nbsp;</p>

<p>&bull; Notas &ndash; cualquier otra informaci&oacute;n, clarificaci&oacute;n, referencia a otra fuentes de<br />
informaci&oacute;n, etc.<br />
Normalmente muy breve.de usuario lento y poco intuitivo es un ejemplo de baja calidad externa.</p>

<p>Calidad interna: se refiere a aquellos aspectos que normalmente no son<br />
visibles al usuario, pero que tienen un profundo efecto en la<br />
mantenibilidad del sistema.</p>

<p>Todo en Scrum tiene una duraci&oacute;n determinada (time-boxed). Me encanta esa<br />
&uacute;nica, simple y consistente regla. Intentamos cumplirla al cien por cien.<br />
Definiendo la duraci&oacute;n del Sprint<br />
Uno de los resultados de la planificaci&oacute;n de Sprint es una fecha de Demo de Sprint definida.<br />
Decidiendo qu&eacute; historias incluir en el Sprint<br />
Una de las principales actividades durante la planificaci&oacute;n de Sprint es decidir<br />
qu&eacute; historias se incluyen en el Sprint. M&aacute;s espec&iacute;ficamente, qu&eacute; historias de la<br />
Pila de Producto copiar en la Pila de Sprint.</p>

<p>&nbsp;</p>

<h2 align="left"><strong>Capitulo 3</strong></h2>

<p align="left">como nos preparamos para la planificaci&oacute;n de un sprint<br />
para ello tenemos que tener la pila de producto perfectamente lista<br />
eso significa que todos los elementos importantes deber&iacute;an tener ratios de importancia<br />
asignados, diferentes ratios de importancia.<br />
El due&ntilde;o de producto debe comprender cada historia</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>capitulo 4</strong></h2>

<p align="left">La planificaci&oacute;n de Sprint es una reuni&oacute;n cr&iacute;tica, probablemente la m&aacute;s<br />
importante de Scrum (en mi subjetiva opini&oacute;n, por supuesto). Una planificaci&oacute;n<br />
de Sprint mal ejecutada puede arruinar por completo todo el Sprint.<br />
El prop&oacute;sito de la planificaci&oacute;n de Sprint es proporcionar al equipo suficiente<br />
informaci&oacute;n como para que puedan trabajar en paz y sin interrupciones durante<br />
unas pocas semanas, y para ofrecer al Due&ntilde;o de Producto suficiente confianza<br />
como para permit&iacute;rselo.<br />
Porque la calidad no se negocia: la calidad. Tiendo a distinguir entre calidad interna y calidad<br />
externa.<br />
Calidad externa: es lo que perciben los usuarios del sistema. Un interfaz<br />
de usuario lento y poco intuitivo es un ejemplo de baja calidad externa.<br />
Calidad interna: se refiere a aquellos aspectos que normalmente no son<br />
visibles al usuario, pero que tienen un profundo efecto en la<br />
mantenibilidad del sistema.</p>

<p align="left">Todo en Scrum tiene una duraci&oacute;n determinada (time-boxed). Me encanta esa<br />
&uacute;nica, simple y consistente regla. Intentamos cumplirla al cien por cien.<br />
Definiendo la duraci&oacute;n del Sprint<br />
Uno de los resultados de la planificaci&oacute;n de Sprint es una fecha de Demo de Sprint definida.<br />
Decidiendo qu&eacute; historias incluir en el Sprint<br />
Una de las principales actividades durante la planificaci&oacute;n de Sprint es decidir<br />
qu&eacute; historias se incluyen en el Sprint. M&aacute;s espec&iacute;ficamente, qu&eacute; historias de la<br />
Pila de Producto copiar en la Pila de Sprint.</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>capitulo 6</strong></h2>

<p align="left"><strong>como hacemos pilas de productos</strong></p>

<p align="left">hemos completado la reuni&oacute;n de planificaci&oacute;n de Sprint e informamos a todos<br />
sobre nuestro Sprint, as&iacute; que hay que crear una Pila de Sprint. Esto debe hacerse<br />
antes de la reuni&oacute;n.</p>

<p align="left"><strong>Formato de la Pila de Sprint </strong></p>

<p align="left">para esto se puede usar excel, jira, o un tabl&oacute;n f&iacute;sico hasta hay aplicaciones que generan<br />
diagramas de burn-down y cosas as&iacute;. Pero el m&eacute;todo mas efectivo seg&uacute;n el autor es una tabla<br />
de tareas en la pared, en la cual pondremos 3 filas la primera con &ldquo;pendiente&rdquo; ,<br />
la segunda con &ldquo; en curso&rdquo; y la tercera con &ldquo;terminado&rdquo; aparte de el diagrama de burn-down&nbsp;y<br />
un espacio para colocar los eventos no planificados que surjan mientras desarrollamos<br />
el trabajo y un lugar donde colocamos historias extras para que cuando se<br />
termine con las tareas a realizar se agarren nuevas de ese lugar.</p>

<p align="left">En la fila pendiente se encuentran todas las historias, luego tomamos algunas en las<br />
que estaremos trabajando y las pasamos al estado de en curso. Y cuando finalizamos<br />
toda esa historia se pasa a la fila de terminado para no volver a tocar esa historia.</p>

<p align="left"><strong>Como funciona el diagrama burn-down</strong></p>

<p align="left">en este diagrama tenemos dos ejes, uno vertical con las historias a realizar, y uno<br />
horizontal, con los d&iacute;as-hombre en el que se trabajan.&nbsp;El diagrama nos da se&ntilde;ales<br />
de alerta con solo darle un vistazo r&aacute;pido, que nos permite darnos cuenta si estamos atrasados<br />
por algunos tickets no planeados, o si vamos demasiado r&aacute;pido con otros tickets.</p>

<p align="left"><strong>Estimando en d&iacute;as o en horas.</strong></p>

<p align="left">Antes en la mayor&iacute;a de los libros se estimaban las tareas en horas y no en d&iacute;as, en el cual<br />
hab&iacute;a una formula para estimar eso la cual es : 1 d&iacute;a = 6 horas hombre.Lo cual ya no se utiliza<br />
por los siguientes motivos:Las estimaciones en horas-hombre eran demasiado tediosas, y esto<br />
provocaba confusi&oacute;n estirar tareas que quiz&aacute;s se hac&iacute;an en menos tiempo.</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 7</strong></h2>

<p align="left"><strong>como distribuimos la sala del equipo.</strong></p>

<p align="left">tratamos de organizar un &aacute;rea como una &ldquo;esquina de dise&ntilde;o&rdquo; , porque se obtiene una vista<br />
general del sistema con solo echar un vistazo a lo m&aacute;s importantes del dise&ntilde;o y la documentaci&oacute;n m&aacute;s importante.<br />
Tenemos que tratar por cualquier medio tener al equipo junto, y mucho mejor si tienen espacio de sobra.<br />
Los resultados van a ser inmediatos porque el equipo tendr&aacute; una mejor<br />
<strong>Audibilidad </strong>ya que todos los miembro del equipo podr&aacute;n hablar con cualquier<br />
otro sin tener que levantarse.<br />
<strong>Visibilidad: </strong>todos los miembros se van a poder ver entre si, y observar el tabl&oacute;n de tareas sin esfuerzo.<br />
<strong>Aislamiento </strong>el equipo no molestara ni sera molestado en sus discusiones.<br />
y si tenemos al equipo distribuidos tendremos que usar la mayor cantidad de t&eacute;cnicas para llevar<br />
adelante lo mejor posible el trabajo.<br />
Tenemos que tratar de mantener al due&ntilde;o del producto cerca as&iacute; el equipo puede preguntarle cosas al respecto.<br />
Pero no dejar que el due&ntilde;o del producto se siente con el equipo ya que este puede hacer preguntas<br />
durante las reuniones y no dejar fluir y seguir el curso natural de estas con interrupciones.</p>

<p align="left">&nbsp;</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 8</strong></h2>

<p align="left"><strong>C&oacute;mo hacemos Scrum diarios ?</strong></p>

<p align="left">Los scrum empiezan exactamente a su hora, cada d&iacute;a en el mismo sitio, es mejor si los hacemos diarios y<br />
frente al tabl&oacute;n de tareas. Normalmente se hacen de 15 minutos y de pie para qno sobrepase ese tiempo.</p>

<p align="left"><strong>Como actualizamos el tabl&oacute;n de tareas</strong></p>

<p align="left">esto se hace a diario y preferentemente cada miembro del equipo va actualizando sus tareas y coloca<br />
sus terminaciones o retrasos por tareas no planificadas, luego en la reuni&oacute;n el scrum m&aacute;ster<br />
va actualizando la pila con tickets qcolocan los miembros del equipo.</p>

<p align="left"><strong>Como tratar con los tardones.</strong></p>

<p align="left">Aca el autor sugiere que cada ves que haya un retraso no justificado se pague en una lata que luego<br />
se utilizara para los d&iacute;as de laboratorio o salidas del equipo.</p>

<p align="left"><strong>Tratando con &ldquo;no se qu&eacute; hacer hoy&rdquo;</strong></p>

<p align="left">en este caso lo que podemos hacer es sincronizar todo, y generar nuevos elementos para que los<br />
que no tengan nada que hacer tomen uno, si esto no funciona, los ponemos a hacer pruebas del sistema.<br />
Y si esto sigue sin funcionar utilizar la Verg&uuml;enza, la asignaci&oacute;n de una tarea, la presi&oacute;n de los<br />
compa&ntilde;eros, o la servidumbre. Y si esto no funciona quitar del equipo a esas personas.</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 9</strong></h2>

<p align="left"><strong>porque insistimos en que todos los sprints acaben en una demo</strong></p>

<p align="left">si es bien ejecutada el equipo se siente bien, otras personas se enteran de lo que hace el equipo,otros<br />
equipos pueden debatir sobre tu trabajo, hacer una demo empuja al equipo a mostrar cosas realmente<br />
terminadas, y si les va mal en esa presentaci&oacute;n, la pr&oacute;xima ves por orgullo les tendr&iacute;a que ir mejor.</p>

<p align="left"><strong>Lista de comprobaci&oacute;n de las demos de sprint</strong></p>

<ul>
	<li align="left">asegurar de presentar claramente el objetivo del sprint.</li>
	<li align="left">Mostrar lo que hace el c&oacute;digo.</li>
	<li align="left">Hacer la demo r&aacute;pida.</li>
	<li align="left">Concentrarse en lo que se hizo.</li>
	<li align="left">Dejar que prueben el producto.</li>
	<li align="left">Y no desviarse de lo mas importante.</li>
</ul>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 10</strong></h2>

<p align="left"><strong>C&oacute;mo hacemos retrospectivas de Sprint</strong></p>

<p align="left">La retrospectiva es el segundo evento m&aacute;s Importante de Scrum (siendo el primero la reuni&oacute;n<br />
de planificaci&oacute;n de Sprint)<br />
ya que se puede ver tus avances (positivos y negativos) del proyecto para mejorarlo.<br />
C&oacute;mo organizamos las retrospectivas&nbsp;<br />
Reservamos 1-3 horas, dependiendo de cu&aacute;nta discusi&oacute;n esperemos.<br />
Participantes: el Due&ntilde;o de Producto, el equipo y yo mismo.<br />
Nos vamos a una reuni&oacute;n cerrada, un rinc&oacute;n c&oacute;modo con sof&aacute;s, el patio&nbsp;del tejado o alg&uacute;n sitio similar.<br />
Que podamos tener una discusi&oacute;n sin&nbsp;interrupciones.<br />
Normalmente no hacemos retrospectivas en la sala del equipo, ya que la&nbsp;atenci&oacute;n de la gente suele diluirse.<br />
Alguien es designado secretario.<br />
El Scrum Master muestra la Pila de Sprint y, con ayuda del equipo,&nbsp;resume el Sprint.<br />
Eventos importantes, decisiones, etc.<br />
Hacemos &ldquo;la ronda&rdquo;. Cada persona tiene una oportunidad de decir, sin&nbsp;ser interrumpida, qu&eacute; piensan<br />
que ha ido bien, que podr&iacute;a haber ido&nbsp;mejor y que piensan que deber&iacute;a hacerse de forma diferente<br />
en el&nbsp;pr&oacute;ximo Sprint.<br />
Observamos la velocidad estimada frente a la real. Si hay una gran&nbsp;diferencia, intentamos analizar por qu&eacute;.<br />
Cuando el tiempo casi se ha acabado, el Scrum Master trata de resumir&nbsp;las sugerencias concretas cobre<br />
qu&eacute; puede hacerse mejor el pr&oacute;ximo&nbsp;Sprint.</p>

<p align="left">&nbsp;</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 11</strong></h2>

<p align="left"><strong>Descansos entre Sprint</strong></p>

<p align="left">El descanso de Sprint se basa en no acumular mucha informaci&oacute;n en un solo dia para el equipo<br />
ya sea que todos puedan estar concentrados y tengan mas din&aacute;mica.</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 12 </strong></h2>

<p align="left"><strong>Como hacemos planificaci&oacute;n de entregas y</strong></p>

<p align="left"><strong>Contratos a precio cerrado</strong></p>

<p align="left">T&iacute;picamente cuando tenemos un contrato a precio cerrado en el que tenemos&nbsp;que planificar por<br />
adelantado, o correr el riesgo de firmar algo que no podemos<br />
entregar a tiempo, con esto nos daremos cuenta cuando, como muy tarde entregaremos nuestro sistema.</p>

<p align="left"><strong>Define tus umbrales de aceptaci&oacute;n</strong></p>

<p align="left">Es la clasificaci&oacute;n de los niveles de importancia de la Pila de Producto en t&eacute;rminos del contrato.<br />
Ejemplo de umbrales de aceptaci&oacute;n:</p>

<p align="left">&bull; Todos los elementos con importancia &gt;=100 deben estar incluidos en la&nbsp;versi&oacute;n 1.0, o seremos penalizados hasta la muerte.<br />
&bull; Todos los elementos de importancia 50-99 deber&iacute;an estar incluidos en&nbsp;la versi&oacute;n 1.0, pero podr&iacute;amos pasar<br />
&nbsp; sin ellos si los incluy&eacute;semos en otra&nbsp;entrega poco despu&eacute;s.<br />
&bull; Los elementos con importancias 25-49 son requisitos, pero podemos&nbsp;incluirlos en una versi&oacute;n 1.1.<br />
&bull; Los elementos con importancia &lt;25 son puramente especulativos y&nbsp;puede que ni siquiera hagan falta.</p>

<h2 align="left">&nbsp;</h2>

<h2 align="left"><strong>Capitulo 13</strong></h2>

<p align="left"><strong>C&oacute;mo combinamos Scrum con XP</strong></p>

<p align="left">El Scrum se enfoca en las pr&aacute;cticas de organizaci&oacute;n y gesti&oacute;n, mientras que XP se centra m&aacute;s en las<br />
pr&aacute;cticas de programaci&oacute;n. Esa es la raz&oacute;n de que funcionen tan bien juntas: tratan de &aacute;reas diferentes<br />
y se complementan entre ellas.</p>

<p align="left"><strong>Programaci&oacute;n por parejas</strong></p>

<p align="left">La programaci&oacute;n en pareja agiliza la forma de trabajar en el proyecto, ya que a la hora de programar mejora<br />
la calidad de los c&oacute;digos, la concentraci&oacute;n del equipo, etc. Pero tambi&eacute;n puede ser agotadora<br />
y por eso se recomienda cambiar parejas.</p>

<p align="left"><strong>Desarrollo guiado por pruebas (TDD)</strong></p>

<p align="left">El Test Driven Development (TDD) se utiliza para principalmente para mejorar la legibilidad y<br />
eliminar duplicaciones (Aclarar y repetir).</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 14</strong></h2>

<p align="left"><strong>C&oacute;mo hacemos pruebas</strong></p>

<p align="left">Es la parte m&aacute;s importante del proyecto, en el cual ves tus errores o tus mejoras a la hora de empezar a interactuar con &eacute;l.<br />
El equipo de pruebas encontrar&aacute; errores, el equipo Scrum tendr&aacute; que hacer las correcciones necesarias, y tarde<br />
o temprano ser&aacute; posible lanzar una versi&oacute;n 1.0.1 a los usuarios finales en lugar de la inestable 1.0.0. La fase<br />
de pruebas es el periodo de pruebas, correcciones y relanzamiento que se busca hasta que haya una versi&oacute;n suficientemente buena.</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 15</strong></h2>

<p align="left"><strong>C&oacute;mo manejar m&uacute;ltiples equipos Scrum</strong></p>

<p align="left">Se basa en la creaci&oacute;n de grupos y como destruir a la gente en cada equipo. Encontraremos una variantes<br />
de equipos como equipos virtuales (se forma un equipo grande pero a su vez se divide en sub-equipos).<br />
A cada equipo se le asigna una tarea diferente para facilitar el trabajo.</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 16</strong></h2>

<p align="left">C&oacute;mo gestionamos equipos distribuidos&nbsp;Geogr&aacute;ficamente<br />
Se basa en facilitar la comunicaci&oacute;n entre las personas ya que pueden debatir a todo momento del tema.<br />
Como por ejemplo:<br />
La posibilidad de programar por parejas juntos<br />
&bull; La posibilidad de encontrarse cara a cara en el Scrum diario<br />
&bull; La posibilidad de tener discusiones cara a cara en cualquier momento<br />
&bull; La posibilidad de encontrarse f&iacute;sicamente y socializar<br />
&bull; La posibilidad de tener reuniones espont&aacute;neas de todo el equipo<br />
&bull; La posibilidad de tener la misma visi&oacute;n de la Pila de Sprint, burn-down deSprint, Pila de Producto y otras fuentes de informaci&oacute;n.</p>

<p align="left">&nbsp;</p>

<h2 align="left"><strong>Capitulo 17</strong></h2>

<p align="left"><strong>Lista de comprobaci&oacute;n del Scrum Master</strong></p>

<p align="left">Se enfoca en mostrar una lista de comprobaci&oacute;n que enumera la mayor&iacute;a de las rutinas administrativas de nuestros Scrum Masters.<br />
<strong>comienzo del Sprint</strong><br />
&bull; Tras la reuni&oacute;n de planificaci&oacute;n de Sprint, crea una p&aacute;gina de informaci&oacute;n. A&ntilde;ade un enlace<br />
a la p&aacute;gina desde la p&aacute;gina principal del Wiki. Imprime la p&aacute;gina y ponla en la pared por la que pase la gente cerca de tu equipo.<br />
&bull; Manda un correo a todo el mundo anunciando que ha comenzado un&nbsp;nuevo Sprint.<br />
Incluye el objetivo del Sprint y un enlace a la p&aacute;gina de&nbsp;informaci&oacute;n del Sprint.<br />
&bull; Actualiza el documento de estad&iacute;sticas de Sprint. A&ntilde;ade tu velocidad&nbsp;estimada,<br />
tama&ntilde;o del equipo, longitud del Sprint, etc.<br />
&bull;Todos los d&iacute;as&nbsp;aseg&uacute;rate de que el Scrum diario comienza y termina a su hora.<br />
&bull; Aseg&uacute;rate de que todas las historias son a&ntilde;adidas o eliminadas de la Pila&nbsp;de Sprint&nbsp;cuando sea necesario para mantener el Sprint en fecha.<br />
&bull;Aseg&uacute;rate de que se notifica al Due&ntilde;o de Producto sobre estos cambios.<br />
&bull; Aseg&uacute;rate de que el equipo mantiene actualizados la Pila de Producto y&nbsp;el burn-down.<br />
&bull; Aseg&uacute;rate de que los problemas o impedimentos son solucionados o&nbsp;reportados al Due&ntilde;o de Producto y/o el Jefe de Desarrollo.</p>

<p align="left">&nbsp;</p>

<p align="left"><strong>Final de Sprint</strong></p>

<p align="left">&bull; Haz una demo de Sprint abierta.<br />
&bull; Todo el mundo deber&iacute;a ser notificado acerca de la demo uno o dos d&iacute;as&nbsp;antes.<br />
&bull; Haz una retrospectiva de Sprint con todo el equipo y el Due&ntilde;o de&nbsp;Producto. Invita al Jefe de Desarrollo tambi&eacute;n, de forma que pueda<br />
ayudar a difundir las lecciones aprendidas.<br />
&bull; Actualiza el documento de estad&iacute;sticas de Sprint. A&ntilde;ade la velocidad real&nbsp;y los puntos clave de la retrospectiva.</p>

